AD-A231  302 


Navy  Personnel  Research  and  Development  Center 

San  Diego,  California  92152-6800  TN-91-4  January  1991 


Development  of  a  USMC 
Officer  Assignment 
Decision  Support  System: 
General  Design  Specification 


Robert  E.  Chatfield 
Stephanie  A.  Gullett 


DT1C 


ELECTE  M 
JAN  2  8 1991  1  I 


Approved  for  public  release:  distribution  is  unlimited. 


NPRDC-TN-91-4 


January  1991 


Development  of  a  USMC  Officer  Assignment  Decision  Support  System: 

General  Design  Specification 


Robert  E.  Chatfield 
Stephanie  A.  Gullett 


Reviewed  by 
Emanuel  P.  Somer 


Approved  and  released  by 
Jules  I.  Borack 

Director,  Personnel  Systems  Department 


Approved  for  public  release; 
distribution  is  unlimited. 


Accession  For 


NTIS  GRAJtl 
DTIC  TAB 
Unannounced 
Justification- 


t 

□ 


By_ 


Distribution/ 


Availability  Codes 
fAva  il— and/or" 
Special 


Dist 


m 


Navy  Personnel  Research  and  Development  Center 
San  Diego,  California  92152-6800 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

OMBNo.  0704-0188 

Public  repotting  burden  for  ihii  collection  of  information  is  estimated  to  avenge  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering 
and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  ihis  burden  estimate  or  any  other  aspect  of  this  collection  of  informa¬ 
tion,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports.  1215  Jefferson  Davis  Highway,  Suite  1205. 
Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington.  DC  20503. 

1 .  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE 

January  1991 

3  REPORT  TYPE  AND  DATES  COVERED 

Tech  Note-Oct  86-Dec  86 

4.  TITLE  AND  SU8TITLE 

Development  of  a  USMC  Officer  Assignment  Decision  Support  System:  General 
Design  Specification 

5  FUNDING  NUMBERS 

Program  Element  0603732M, 

Work  Unit  M5402688WRRD8FY 

6.  AUTHOR(S) 

Robert  E.  Chatficld,  Stephanie  A.  Gullctt 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Navy  Personnel  Research  and  Development  Center 

San  Diego,  California  92152-6800 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

NPRDC-TN  -91-4 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

USMC  Manpower  Systems  Development  and  Integration  Branch  (Ml-40) 
Washington,  DC  20380-0001 

10  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  is  unlimited. 

1 

12b  DISTRIBUTION  CODE 

1 3.  ABSTFIACT  (Maximum  200  words) 

This  general  design  specification  was  completed  as  part  of  the  Life  Cycle  Management  (LCM)  process  for  development  of  an 
Officer  Assignment  Decision  Support  System  (OADSS).  This  document  details  users’  requirements  for  enhanced  capabilities  for 
carrying  out  assignment  of  Marine  Corps  officers  and  describes  the  Automated  Data  Processing  Equipment  (ADPE)  environment 
required  to  meet  the  proposed  system’s  objectives.  Deficiencies  in  the  current  assignment  system,  as  well  as  capabilities  of  the 
proposed  system  designed  to  correct  them,  are  summarized.  General  design  specifications  are  based  primarily  upon  derivation  of  the 
New  Physical  Model  that  was  established  via  prescribed  structured  analysis  techniques.  This  model  is  composed  of  three  primary 
components:  (1)  data  flow  diagram,  (2)  data  dictionary,  and  (3)  mini-specifications  governing  the  transformation  of  input  data  flows 
that  mini-systems  perform  at  the  primitive  functional  level.  A  Data  Flow  Diagram  (DFD)  is  provided  to  graphically  represent  data 
flows  into  and  out  of  the  seven  functional  mini-systems  (processors).  Also,  an  Entity-relationship  Diagram  (ERD)  is  presented  that 
partitions  data  elements  into  homogeneous  groups  or  entities.  Finally,  factors  such  as  organizational  context,  new  performance 
characteristics,  and  information  requirements  affecting  system  development  are  discussed  as  well. 

(  ! 

14,  SUBJECT  TERMS 

Officer  assignment,  decision  support  system,  automated  information 

15  NUMBER  OF  PAGES 

41 

16  PRICE  CODE 

17.  SECURITY  CLASSIFICA¬ 
TION  OF  REPORT 
UNCLASSIFIED 

18  SECURITY  CLASSIFICA¬ 
TION  OF  THIS  PAGE 
UNCLASSIFIED 

19  SECURITY  CLASSIFICA¬ 
TION  OF  ABSTRACT 
UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UNLIMITED 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev  2-89) 
Prescribed  by  ANSI  Sid.  Z39- 18 
298-102 


FOREWORD 


This  report  describes,  in  general  terms,  the  structure  of  the  data  base  to  be  included  in  the 
Officer  Assignment  Decision  Support  System  (OADSS)  designed  to  improve  officer  assignment 
procedures  in  the  United  States  Marine  Corps  (USMC).  Among  deficiencies  in  the  current 
assignment  system  are  the  labor-intensive  review  of  hard  copy-based  information,  need  for  a 
comprehensive  and  centralized  data  base,  and  lack  of  standardization  among  officer  Monitors  in 
their  assignment  strategies.  Monitors  critically  need  interactive,  computer-based  support  for 
assignment  decisions  because  of  the  volume  of  assignment-related  information  available  and  the 
vast  number  of  assignment  alternatives  to  be  weighed. 

This  is  the  seventh  in  a  series  of  reports  that  detail  the  “concept  development”  and  “definition 
and  design”  phases  of  the  USMC  Life  Cycle  Management  (LCM)  process  associated  with  OADSS. 
The  research  was  conducted  under  program  element  0603732M,  work  unit  M5402688WRRD8FY, 
Marine  Corps  Decision  Support  System  for  Officer  Assignment,  sponsored  by  the  Manpower 
Systems  Development  and  Integration  Branch  (MI).  This  report  is  based  upon  the  General  Design 
Specification  (GDS)  that  was  submitted  to  MI  in  December  1986.  The  present  report  has  been 
revised  to  be  somewhat  less  technical  in  content  and  serves  as  a  guide  for  other  researchers  tasked 
with  drafting  LCM  documentation.  Future  publications  will  include  a  Detailed  Design 
Specification  (DDS)  and  descriptions  of  implementing  system  module  prototypes. 


JULES  I.  BORACK 
Director,  Personnel  Systems  Department 

PRIOR  OFFICER  ASSIGNMENT  DECISION  SUPPORT 
SYSTEM  PUBLICATIONS 

Chatfield,  R.  E.  (1988).  Development  of  a  USMC  officer  assignment  decision  support  system: 
Needs  assessment  (NPRDC-TN-88-50).  San  Diego:  Navy  Personnel  Research  and 
Development  Center.  (AD- A 198353) 

Chatfield,  R.  E.,  &  Gullett,  S.  A.  (1989).  Development  of  a  USMC  officer  assignment  decision 
support  system:  Feasibility  study  (NPRDC-TN-89-14).  San  Diego:  Navy  Personnel  Research 
and  Development  Center. 

Chatfield,  R.  E.,  &  Gullett,  S.  A.  (1989).  Development  of  a  USMC  officer  assignment  decision 
support  system:  Economic  analysis  (NPRDC-TN-89-36).  San  Diego:  Navy  Personnel 
Research  and  Development  Center. 

Chatfield,  R.  E.,  &  Gullett,  S.  A.  (1989).  Development  of  a  USMC  officer  assignment  decision 
support  system:  Functional  description  (NPRDC-TN-89-32).  San  Diego:  Navy  Personnel 
Research  and  Development  Center. 

Chatfield,  R.  E.,  &  Gullett,  S.  A.  (1989).  Development  of  a  USMC  officer  assignment  decision 
support  system:  Data  requirements  (NPRDC-TN-90-12).  San  Diego:  Navy  Personnel 
Research  and  Development  Center. 

Chatfield,  R.  E.,  &  Gullett,  S.  A.  (1991).  Development  of  a  USMC  officer  assignment  decision 
support  system:  Project  management  plan  (in  process).  San  Diego:  N?.vy  Personnel  Research 
and  Development  Center. 


v 


SUMMARY 


Background 

Officer  Monitors  need  support  in  their  decision-making  process  due  to  the  volume  of 
assignment-related  information  to  be  considered  and  the  vast  number  of  assignment  alternatives  to 
be  weighed.  It  is  anticipated  that  a  user-friendly,  interactive  Officer  Assignment  Decision  Support 
System  (OADSS)  will  help  Monitors  better  implement  USMC  staffing  policy,  significantly  reduce 
their  clerical  workload,  and  enhance  the  match  of  officers  to  billets. 


Purport 


The  purpose  of  this  general  design  specification  was  to:  (1)  detail  users'  requirements  for  new, 
revised,  or  enhanced  capabilities  in  carrying  out  assignment  of  Marine  Corps  officers,  and  (2) 
describe  the  Automated  Data  Processing  Equipment  (ADPE)  environment  required  to  meet  the 
proposed  system's  objectives. 

The  New  Physical  Model 

The  OADSS  is  being  developed  to  provide  an  easy-to-use,  interactive  automated  information 
system  for  use  by  Monitors  in  the  assignment  process.  However,  OADSS  will  strictly  serve  as  a 
computer-based  decision  aid  and  is  not  intended  to  automate  assignment  decisions.  Deficiencies  in 
the  current  assignment  system  as  well  as  capabilities  of  the  proposed  system  designed  to  correct 
them  are  summarized.  Deficiencies  in  the  present  system  include:  (1)  lack  of  standardization  among 
Monitors  in  assignment  decision-making  strategies,  (2)  lack  of  user-friendly  procedures  for  ad  hoc 
query  and  data  retrieval,  (3)  manual,  labor-intensive  procedures  for  reviewing  assignment-relevant 
data,  and  (4)  inadequate  and  informal  training  for  Monitors.  The  proposed  system  will  support 
existing  functional  capabilities  as  well  as  provide  new  features  such  as:  (1)  development  of 
specialized,  computer-based  training  for  orientation  of  new  Monitors,  (2)  inclusion  of 
“applications  generator”  technology  to  promote  user-friendliness  in  ad  hoc  query  and  report 
generation,  (3)  expanded  scope  of  computer-resident  data  to  include  information  critical  for  the 
assignment  process  that  is  presently  not  readily  available,  and  (4)  computerization  of  procedures 
that  are  currently  conducted  via  slow,  manual  processing. 

General  Design  Specification 

Design  specification  for  OADSS  is  based  primarily  upon  derivation  of  the  New  Physical 
Model  that  was  established  via  prescribed  structured  analysis  techniques.  The  model  is  essentially 
a  refinement  of  the  logical  model  presented  in  the  earlier  Functional  Description  (FD)  (Chatfield 
&  Gullett,  1988).  That  is,  each  model  is  composed  of  three  primary  components:  (1)  data  flow 
diagram,  (2)  data  dictionary,  and  (3)  mini-specifications  governing  the  transformation  of  input  data 
flows  into  output  data  flows  that  mini-systems  perform  at  the  functional  primitive  level.  The 
model's  organization  is  structured  to  reduce  complexity  by  partitioning  into  functional  subsystems. 
A  detailed  Data  Flow  Diagram  (DFD)  is  presented  to  graphically  represent  data  flows  into  and  out 
of  the  seven  functional  mini-systems  (processors).  A  “leveled  set”  of  DFDs  is  presented  to  detail 
the  top-down  modeling  process  and  intetTelationship  among  mini-systems.  Also,  an  Entity- 
relationship  Diagram  (ERD)  is  presented  that  partitions  elements  from  the  data  dictionary  in  the 
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earlier  data  requirements  publication  (Chatfield  &  Gullett  1990)  into  homogeneous  entities. 
Finally,  factors  such  as  organizational  context,  ADPE  environment  performance  characteristics, 
and  information  requirements  affecting  system  development  are  discussed  as  well. 

Recommendations 

1.  A  Detailed  Design  Specification  (DDS)  should  be  completed  by  the  system  designer  (i.e., 
NPRDC)  as  the  next  step  in  the  “definition  and  design”  phase  of  system  development. 

2.  In  concert  with  the  modular  approach  to  system  development,  “rapid  prototyping”  should 
be  used  as  a  means  of  minimizing  system  development  time  and  ensuring  the  active  participation 
of  end  users. 
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INTRODUCTION 


Background 

The  mission  of  the  Officer  Assignment  Branch  (MMOA),  located  at  Headquarters,  United 
States  Marine  Corps  (HQMC)  is  to  administer  assignment  of  all  Marine  Corps  officers  (colonel  and 
below)  in  accordance  with  regulations,  approved  assignment  policies,  and  criteria  of  the 
Commandant  of  the  Marine  Corps  (CMC).  Functions  carried  out  in  support  of  this  mission  include: 
issuing  travel  orders;  classifying/reclassifying  officers  in  occupational  specialties;  and  assigning 
officers  to  career,  intermediate,  and  top-level  schools.  The  individuals  within  MMOA  who  make 
assignment  decisions  (subject  to  approval  by  higher  authority)  are  referred  to  as  officer 
“Monitors.”  Monitors  have  a  very  difficult  job  in  that  they  are  expected  to  accommodate  both  the 
manning  requirements  of  the  Marine  Corps  and  the  career/personal  needs  of  officers  via  the 
assignment  process.  Performing  this  task  requires  concurrent  consideration  of  the  job  dimensions 
of  available  billets  and  the  skills  and  attributes  of  officers  being  assigned. 

Monitors’  first  consideration  in  staffing  is  the  “fill”  of  available  billets,  while  the  next  is  the 
“fit”  of  officers  to  specific  billets  based  upon  their  education,  work  experience.  Military 
Occupational  Specialty  (MOS),  etc.  The  process  of  reaching  an  assignment  decision  may  involve 
accessing  on-line  personnel  databases  such  as  the  Joint  Uniform  Military  Pay  System/Manpower 
Management  System  (JUMPS/MMS),  reviewing  Officer  Fitness  Reports  (FITREPS)  on 
microfiche,  talking  with  constituents  in  person  or  on  the  telephone,  or  reviewing  a  number  of  other 
relevant  sources  of  information.  In  conjunction  with  this,  Monitors  must  also  be  mindful  of 
established  staffing  policy,  United  States  Marine  Corps  (USMC)  manning  levels,  and  the  career 
development  needs  of  individual  officers  when  weighing  assignment  alternatives. 

The  idea  for  establishing  an  Officer  Assignment  Decision  Support  System  (OADSS)  came 
about  because  it  was  evident  that  Monitors  need  support  in  their  decision-making  process  due  to 
the  vast  amount  of  assignment-related  information  to  be  considered  and  the  number  of  assignment 
alternatives  to  be  weighed.  It  is  anticipated  that  a  truly  user-friendly,  interactive  Decision  Support 
System  (DSS)  will  help  Monitors  better  implement  USMC  staffing  policy,  significantly  reduce 
their  clerical  workload,  and  enhance  the  match  of  officers  to  billets. 

The  original  effort  to  develop  a  DSS  for  Monitors  was  carried  out  by  a  contractor  as  part  of  the 
Officer  Precise  Personnel  Assignment  System  (Officer  PREPAS)  in  1979.  However,  this  work 
stressed  an  optimization  approach  to  officer  assignment  and  was  terminated  in  the  early  concept 
development  stage  of  the  Life  Cycle  Management  (LCM)  process.  A  subsequent  contractor  effort 
to  build  OADSS,  in  1981,  was  also  terminated  in  the  concept  development  stage  as  it  also  relied 
too  heavily  upon  optimization  techniques  and  was  not  sufficiently  interactive.  Both  of  these 
attempts  were  doomed  to  failure  as  the  Marine  Corps  objected  to  any  “black  box”  (i.e., 
optimization)  approach  perceived  to  automate  the  assignment  process.  The  goal  was  to  support 
Monitors  in  their  decision-making,  not  to  make  assignment  decisions  for  them. 

The  idea  for  developing  the  OADSS  lay  dormant  until  1985  when  support  for  a  third  attempt 
at  system  development  became  available  at  the  Navy  Personnel  Research  and  Development  Center 
(NPRDC).  The  project  sponsor,  the  Manpower  Systems  Development  and  Integration  Branch 
(MI),  specified  that  system  design  be  carried  out  by  Personnel  Research  Psychologists  rather  than 
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Operations  Researchers  or  Computer  Specialists  under  the  assumption  that  this  would  avoid  yet 
another  optimization-oriented  approach  that  would  prove  unacceptable  to  the  CMC.  Also,  it  was 
Manpower  Management  Information  (MPI)  Systems  Branch  assumption  that  the  psychologists 
could  better  assess  Monitors’  needs  and  translate  them  into  design  of  a  system  that  was  easy  to 
access  and  truly  user-friendly. 

In  compliance  with  the  USMC  Life  Cycle  Management  Plan  of  Automated  Information 
Systems  (LCM-AIS),  Marine  Corps  Order  P5231.1,  a  combined  General  Design  Specification/ 
Detailed  Design  Specification  (GDS/DDS)  was  submitted  to  MPI  in  December  1986.  This  current 
technical  note  is  based  upon  the  General  Design  Specification  (GDS)  submitted  to  MPI  and  has 
been  revised  to  be  somewhat  less  technical  in  content.  This  report  can  also  serve  as  a  guide  for  other 
researchers  tasked  with  drafting  LCM  documentation. 

Purpose 

The  GDS  details  users’  requirements  for  new,  revised,  or  enhanced  capabilities  in  carrying  out 
the  assignment  of  Marine  Corps  officers.  In  addition,  it  details  the  Automated  Data  Processing 
Equipment  (ADPE)  environment  required  to  meet  the  proposed  system’s  stated  purpose.  Paired 
with  information  about  applications  software  provided  in  the  Detailed  Design  Specification 
(DDS),  this  document  will  provide  a  complete  overview  of  what  is  required  to  implement  a 
“prototype”  OADSS. 

Project  References 

A  variety  of  publications  were  reviewed  throughout  the  course  of  GDS  development.  Among 
the  most  important  are  the  following: 

Automated  Data  System  (ADS)  Plan  for  the  Officer  Precise  Personnel  Assignment  System  (Officer 
PREP  AS),  Potomac  Research  Incorporated  and  General  Research  Corporation,  15  September 
1979.  This  report  presents  a  proposal  for  development  of  the  Officer  PREPAS  System  and  an 
assignment  management  information  system. 

Development  of  Specifications  for  the  Officer  Assignment  Decision  Support  System,  Andrulis 
Research  Corporation,  25  February  1981.  This  report  presents  a  proposal  for  development  of 
an  officer  assignment  system  based  on  optimization  strategies. 

Officer  Staffing  Goal  Model  (OSGM):  Design  Specifications,  Decision  Systems  Associates,  June 
1978.  This  report  contains  a  description  of  the  function,  logic,  and  data  definitions  of  the 
OSGM  at  the  time  of  development. 

Users  Manual:  Officer  Staffing  Goal  Model  (OSGM),  Decision  Systems  Associates,  September 
1984.  This  manual  describes  how  to  create  and  run  an  OSGM  job. 

Marine  Corps  Personnel  Assignment  Policy,  Marine  Corps  Order  1300.8M,  2  May  1984.  This 
Marine  Corps  Order  (MCO)  implements  Department  of  Defense  policy  and  provides  policy 
guidance  relative  to  assignment  and  permanent  change  in  station  (PCS)  of  Marines. 
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Officer  Assignment  Branch  Slating  Guidance  Memorandum,  Director,  Personnel  Management 
Division,  18  October  1982.  This  memorandum  provides  guidance  for  the  slating  process, 
amplifies  existing  instructions,  and  establishes  branch  policies  not  covered  elsewhere. 

Joint  Uniform  Military  Pay  System/Manpower  Management  Systems  Code  Manual,  Marine  Corps 
Order  P-1080.20,  current  to  1 1  December  1984.  This  manual  contains  definitions  used  in  the 
JUMPS/MMS  and  REMMPS  system. 

Staffing  Precedences  for  Officer  and  Enlisted  Billets,  Marine  Corps  Order  5320. 12,  22  June  1982. 
This  MCO  establishes  personnel  management  guidance  and  staffing  precedences  for  officer 
and  enlisted  billets  in  Marine  Corps  Commands. 

Life  Cycle  Management  for  Automated  Information  Systems  (LCM-AIS),  Marine  Corps  Order  P- 
5231 .1, 9  August  1983.  This  MCO  establishes  policies,  procedures,  and  regulations  governing 
the  development,  operation,  and  management  of  automated  information  systems. 

System  Development  Methodology:  Volume  III  Standards,  Marine  Corps  Order  P5231.1A,  Draft 
of  June  1986.  This  MCO  modifies  the  policies,  procedures,  and  regulations  presented  in  Marine 
Corps  Order  P5231.1A  and  includes  several  new  documentation  requirements. 

Automated  Data  Systems  (ADS)  Documentation,  Department  of  Defense  Standard  7935,  15 
February  1983.  This  document  provides  Department  of  Defense  (DoD)  guidelines  for  the 
development  and  revision  of  documentation  for  ADSs  and  describes  technical  documents  to  be 
produced  throughout  the  life  cycle  of  an  ADS. 

Approach 

The  GDS  represents  the  product  of  structured  systems  analysis;  specifically,  the  New  Physical 
Model.  This  model  defines  the  operational  environment  of  the  proposed  system  and  includes  the 
following  elements; 

1.  General  information  about  system  objectives,  scope  of  development  activities, 
responsibilities  of  the  system  development  team,  and  other  cogent  recommendations. 

2.  Context  Diagram,  or,  in  the  case  of  a  designated  subsystem,  a  Relative  Context  Diagram. 

3.  A  leveled  set  of  Data  Flow  Diagrams  (DFDs)  comprised  of  a  Figure  0  and  associated  child 
figures  inclusive  to  the  functional  primitive  level. 

4.  Mini-specifications  for  all  functional  primitives  declared  on  the  lowest  level  child  figures. 

5.  References  to  the  Data  Dictionary  included  in  the  earlier  Data  Requirements  Document 
(DRD)  for  all  data  declared  on  the  DFDs. 

6.  Relevant  supplemental  information  such  as  performance  characteristics,  ADPE 
environment,  and  summaries  of  required  changes  to  current  operational  procedures. 


In  the  interest  of  promoting  readability,  the  terms,  definitions,  and  acronyms  used  throughout 
the  GDS  are  presented  in  Appendix  A. 

As  indicated  in  Marine  Corps  Order  P5231.1A,  modeling  the  General  Design  is  the  second  step 
in  the  prescribed  method  of  structured  systems  analysis.  This  step  builds  upon  information 
provided  in  the  earlier  Functional  Description  (FD)  and  DRD.  The  completed  General  Design 
considers  the  physical  constraints  (office  space,  equipment,  etc.)  attendant  to  both  the 
organizational  and  technological  limitations  of  the  new  system’s  operational  environment. 
Specifically,  the  following  factors  are  considered: 

1.  The  capacity,  capability,  and  efficiency  of  the  operative  hardware  and  software 
environment. 

2.  The  organizational  responsibilities  (i.e.,  mission)  and  job  descriptions  related  to  the 
implementation  environment. 

3.  The  geographical  allocations  required  in  the  new  requirements;  specifically,  as  the 
proposed  system  interfaces  with  the  Marine  Corps  Central  Design  and  Programming  Activity 
(MCCDPA),  Regional  Automated  Service  Center  (RASC),  or  Deployable  Force  Automated 
Service  Center  (DFASC). 

4.  The  anticipated  or  desired  performance  characteristics  of  the  new  system. 

In  developing  the  General  Design,  essential  and  custodial  functions  are  allocated  to  a  endant 
physical  processors  based  on  a  careful  assessment  of  the  planned  implementation  environment  and 
data  requirements  are  modeled  to  meet  the  physical  reporting  and  storage  requirements  of  the  new 
system.  Finally,  implementation-dependent  functions  are  added  to  the  model  to  perform 
administrative  tasks  such  as  edits,  audits,  data  validation,  and  report  formatting.  The  General 
Design  process  is  considered  to  be  complete  with  production  of  a  New  Physical  Model  that 
includes. 

1.  Delineation  of  all  functions  necessary  to  meet  the  new  system’s  stated  purpose  follow  ing 
implementation. 

2.  A  description  of  all  data  required  to  satisfy  the  new  system’s  stated  purpose  following 
implementation. 

3.  A  discussion  of  all  man-machine  interfaces;  specified  at  the  topmost  level. 

THE  NEW  PHYSICAL  MODEL 

This  section  describes  the  New  Physical  Model  as  developed  in  accordance  with 
documentation  requirements  set  forth  in  the  draft  version  of  “System  Development  Methodology, 
Volume  III:  Standards  of  Marine  Corps  Order  P5231.1  A  (Supplement  Number  7:  General  Design 
Specification  Standard).” 
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System  Objective 


The  OADSS  is  being  dev'  doped  to  provide  an  easy-to-use,  interactive  automated  information 
system  for  use  by  officer  Monitors  in  the  assignment  process.  However,  OADSS  will  strictly  serve 
as  a  computer-based  decision  aid  and  is  not  intended  to  automate  assignment  decisions.  The 
proposed  system  will  free  Monitors  trom  the  manual,  labor-intensive  review  of  data  elements  and 
thus  provide  more  time  for  interacting  with  constituents,  ensuring  assignments  comply  with 
staffing  guidance,  and  weighing  assignment  alternatives.  The  deficiencies  in  the  current 
assignment  system  as  well  as  the  capabilities  of  the  proposed  system  designed  to  correct  them  are 
briefly  summarized  below. 

Deficiencies  in  the  Present  System 

User  requirements  are  not  adequately  met  by  the  present  system  due  to  the  following 
deficiencies: 

1.  There  is  a  lack  of  standardization  among  officer  Monitors  in  assignment  procedures  and 
associated  decision-making  stiategies.  Much  of  this  variation  in  Monitor  “style”  is  attributable  to 
the  lack  of  adequate  training/orientation  procedures. 

2.  Existing  methods  of  searching,  sortirg,  and  dis  "ing  data  (ad  hoc  query  and  data 
retrieval)  with  the  existing  Database  Management  System  (DBMS)  are  not  user-friendly.  As  a 
result,  the  majority  of  Monitors  do  not  effectively  utilize  computer-based  assistance  in  carrying  out 
their  assignment  responsibilities. 

3.  Available  computer  databases  do  not  contain  all  of  the  data  elements  Monitors  need  to 
reference  in  making  assignment  decisions. 

4.  A  number  of  data  elements  (e.g.,  education  and  experience  codes)  are  misleading  and  not 
indicative  of  actual  skills  and  qualifications. 

5.  Review  of  data  elements  is  characterized  by  manual,  labor-intensive  procedures  that  are 
time-consuming  and  burdensome  for  Monitors. 

6.  Extensive  redundancy  and  duplication  of  effort  exists  in  database  maintenance  procedures 
(e.g.,  updating  the  Officer  Slate  File  (OSF))  is  problematic. 

7.  Data  element  accuracy  is  often  questionable  and  must  be  verified/corrected  by  Monitors. 

8.  Update/modification  of  the  Officer  Staffing  Goal  Model  (OSGM)  Dictionary  is  fragmented 
and  excessively  time-consuming. 

9.  Monitors’  input  to  the  OSGM  Dictionary  is  often  not  well  considered  and  reviewed, 
resulting  in  staffing  goals  of  questionable  validity. 

10.  Training  for  Monitors  is  unacceptable;  materials  are  not  tailored  for  their  responsibilities 
and  formal  training  sessions  are  not  well  structured. 
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Capabilities  of  the  Proposed  System 

The  proposed  system  will  support  all  existing  functional  capabilities  and  provide  the  following 
new  capabilities  to  correct  deficiencies: 

1 .  Computer-based  interactive  maintenance  of  the  OSGM  Dictionary  to  be  used  by  Monitors. 

2.  Development  of  an  Automated  Monitor  Orientation  Subsystem  (AMOS)  to  improve 
training  and  orientation  of  Monitors. 

3.  User-friendly  methods  of  querying  the  OADSS  database  to  be  based  on  “Applications 
Generator”  technology.  This  feature  will  include  a  versatile,  easy-to-use  report  generator. 

4.  Expanded  availability  of  computer-based  data  elements  to  include  information  critical  to 
the  assignment  process  that  is  not  presently  readily  available. 

5.  Increased  reliability  and  responsiveness  of  computer  resources  supporting  MMOA. 

6.  Computerization  of  procedures  that  are  currently  inefficiently  conducted  via  slow,  manual 
processing. 

Scope 

The  proposed  system  will  be  implemented  within  the  MMOA  located  at  HQMC.  The  mission 
of  MMOA  is  to  administer  assignments  for  all  Marine  Corps  officers  (colonels  and  below)  in 
accordance  with  regulations,  approved  assignment  policies,  and  criteria  of  the  CMC.  Functions 
carried  out  in  support  of  this  mission  include:  issuance  of  travel  orders,  classification  and 
reclassification  of  officers,  entering  data  into  the  JUMPS/MMS,  and  assigning  officers  to  career, 
intermediate,  and  top  level  schools.  Authority  for  this  mission  is  contained  in  numerous  MCOs  and 
is  summarized  in  paragraph  2512  of  Headquarters,  U.S.  Marine  Corps  Order  (HQO)  P5400.18 
Headquarters,  U.S.  Marine  Corps  Organizational  Manual  (HQORGMAN).  While  MMOA  is 
satisfactorily  carrying  out  its  mission,  there  are  several  areas  that  need  improvement.  One  key  area 
of  concern  is  Monitors’  input  to  the  OSGM  via  the  Dictionary  process.  This  responsibility  is  a  low 
priority  for  them  and  they  frequently  “fix”  manpower  resources  resulting  in  generation  of  staffing 
goals  that  are  misleading  and  of  questionable  validity.  Another  area  needing  improvement  is 
Monitors’  review  of  assignment-relevant  data  elements.  As  the  present  DBMS  does  not  provide 
user-friendly  methods  ot  ad  hoc  query  and  report  generation,  the  majority  of  Monitors  use  labor- 
intensive,  manual  procedures.  Increased  utilization  of  computer-based  decision  aids  will  make 
Monitors’  jobs  easier  and  allow  them  more  time  to  interact  with  constituents,  review  assignment 
alternatives,  etc.  To  address  the  range  of  deficiencies  identified  in  the  earlier  Needs  Assessment 
(Chatfield,  1988),  the  proposed  system  must  be  a  multi-disciplinary,  broad-based  effort. 
Additionally,  a  modular  approach  will  be  used  to  develop  system  capabilities  to  correct  cited 
deficiencies.  The  focus  of  OADSS  is  on  integrating  existing  AISs  into  a  centralized,  cohesive 
system  that  will  provide  Monitors  with  all  of  the  resources  needed  to  effectively  carry  out  the 
mission  of  MMOA. 
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GENERAL  DESIGN  SPECIFICATION 

The  New  Physical  Model,  established  through  prescribed  structured  analysis  techniques, 
should  be  sufficient  to  meet  user  needs  upon  implementation.  That  is,  it  specifies  such  system 
components  as  ADPE  environment,  information  needs,  etc.  that  are  required  to  accomplish  system 
objectives.  Modules  (subsystems)  of  OADSS  will  be  developed  on  a  “prototype”  basis  and  tested 
on  a  small-scale  before  full  integration  into  the  MMOA  working  environment.  This  will  enable  the 
developer  to  “fine  tune”  each  module  by  working  closely  with  end  users  r  he  subsystem 
evaluation  phase.  The  operational  and  functional  capabilities  of  the  system  will  bv  .ully  tested  in  a 
microcomputer  environment  before  transfer  to  the  MCCDPA,  Quantico,  mainframe  computer. 
Procurement  of  a  MMOA-dedicated  minicomputer  to  run  OADSS  and  other  MMOA  models/ 
systems  was  initially  recommended,  however,  this  was  not  feasible  due  to  funding  and  manpower 
constraints.  However,  applications  software  will  be  selected  which  are  transportable  to  a 
minicomputer  should  this  procurement  become  a  reality  at  some  future  point.  The  New  Physical 
Model  serves  as  the  basis  for  development  of  the  GDS  as  well  as  the  subsequent  DDS. 

Structured  Specification 

The  Structured  Specification  presented  here  is  a  product  of  the  Structured  Analysis  approach 
and  it  provides  a  model  for  both  the  system  under  development  and  all  associated  documentation. 
However,  it  is  also  useful  for  the  system  developer  and  prospective  users  alike  to  communicate 
system  performance  requirements.  The  subsections  to  follow  provide  a  comprehensive  summary 
of  the  model  developed.  Issues  related  to  system  components,  organizational  environment, 
supporting  tools  required,  and  criteria  for  ensuring  internal  consistency  and  completeness  will  be 
discussed.  The  discussion  will  be  limited  to  the  New  Physical  Model  as  that  is  the  focus  of  this 
technical  publication. 

Conceptual  Model  Organization 

The  physical  model  developed  for  the  GDS  is  essentially  a  refinement  of  the  logical  model 
presented  in  the  earlier  FD  (Chatfield  &  Gullett,  1988).  That  is,  each  model  is  composed  of  three 
primary  components: 

1 .  Data  Row  Diagram  (DRD)--a  network  of  related  mini-systems  and  the  data  flows  and  data 
stores  interfacing  those  mini-systems. 

2.  Data  Dictionary-a  set  of  definitions  of  data  flows  and  data  stores  declared  on  the  DR). 

3.  Mini- specification  (mini-spec )-a  statement  of  rules  governing  the  transformation  of  input 
data  flows  into  output  data  flows  that  mini-systems  perform  at  the  functional  primitive  level. 

These  components  are  organized  in  such  a  manner  as  to  eliminate  redundancy  in  specification 
of  system  requirements.  That  is,  the  model’s  organization  is  structured  to  reduce  complexity  by 
partitioning  the  model  into  functional  subsystems.  This  strategy  will  aid  in  system  development 
and  promote  the  active  participation  of  users  in  system  design  and  implementation. 
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Data  Flow  Diagram  (DFD) 


A  DFD  provides  a  graphic  network  of  related  mini-systems  (processors)  and  all  data  flows  and 
data  stores  interfacing  with  those  mini-systems.  The  following  discussion  of  DFD  components  is 
provided  to  aid  the  reader  in  interpretation  of  the  figures  which  follow: 

1.  Data  Flow-a  curved  line,  or  arc,  that  represents  the  flow  of  information  or  data.  Each  arc 
has  an  arrow  (or  arrows)  indicating  direction  of  the  data  flow.  The  name  of  the  data  flow  is  written 
next  to  the  arc  to  represent  its  content. 

2.  Mini-system  (or  process)-a  circle  that  represents  a  transformation  of  incoming  data  into 
outgoing  data.  The  name  of  the  mini-system  is  written  within  the  circle  to  describe  its  function. 

3.  Data  Store-a  set  of  parallel  lines  used  to  represent  a  repository  of  data.  This  includes  all 
data  stored  by  the  system  or  accessed  by  its  mini-systems.  The  name  of  the  data  store  is  written 
between  the  parallel  lines  to  summarize  its  content. 

The  DFD  for  OADSS  is  presented  in  Figure  1.  OADSS  is  comprised  of  seven  functional  mini¬ 
systems:  five  of  which  are  primarily  data  store-intensive.  This  orientation  is  to  be  expected  as 
OADSS’  major  emphasis  is  upon  providing  improved  database  query,  data  retrieval,  and  reporting 
procedures  to  Monitors.  The  numerous  input  arcs  from  mini-systems  to  the  six  data  stores 
illustrated  make  the  DFD  appear  more  complex  than  it  actually  is,  however.  The  five  data  store¬ 
intensive  mini-systems  all  perform  some  aspect  of  the  data  management  process  and  are  necessary 
to  provide  MMOA  with  access  to  all  assignment-related  information.  The  “Provide  User  Training” 
mini-system  is  the  only  one  that  operates  in  essentially  a  stand-alone  mode.  While  many  of  its 
lessons  will  mirror  DBMS  utilization  (via  OADSS),  only  sample  databases  will  be  used. 

Context  Diagram 

The  context  diagram,  also  referred  to  as  the  relative  context  diagram,  provides  a  top-level 
graphic  representation  of  the  system.  While  the  diagram  depicts  all  net  inputs  to  and  net  outputs 
from  the  system,  no  partitioning  of  the  system  components  is  included.  The  context  diagram  is 
composed  of  the  following: 

1 .  Net  Data  Flow— a  curved  line,  or  arc,  that  represents  the  net  flow  of  information  into  or  out 
of  the  system.  Each  arc  has  an  arrow  (or  arrows)  indicating  direction  of  the  net  data  flow.  The  name 
of  the  net  data  flow  is  written  next  to  the  arc  to  represent  its  content. 

2.  System— a  circle  that  represents  the  entire  system,  or  subsystem,  under  development.  The 
name  of  the  system  is  written  within  the  circle. 

3.  Source/Destination— a  rectangle  that  represents  a  source  or  destination  for  respective 
system  inputs  and  outputs.  The  name  of  the  source/destination  is  written  within  the  rectangle. 

The  context  diagram  for  OADSS  is  presented  in  Figure  2.  Four  specific  organizational  entities 
(or  activities)  will  interface  with  the  system  for  input/output  purposes.  The  first,  MMOA,  is  the 
primary  system  user.  MMOA’s  input  will  consist  of  data  element  updates  and  various  processing 
requests  (e.g.,  ad  hoc  query).  System  output  to  MMOA  will  include  ad  hoc  query  feedback,  repons. 
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Figure  1.  Data  flow  diagram  (DFD). 
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■  Or  wherever  OSGM  is  run 


Figure  2.  Context  diagram. 


and  training  sessions.  The  second  interface  with  OADSS,  by  the  Manpower  Management 
Promotions  Branch  (MMPR),  is  represented  by  input  in  the  form  of  the  promotions  database.  The 
third  and  most  critical  system  interface  is  with  the  MCCDPA,  Quantico.  As  OADSS  will  operate 
in  a  mainframe  environment,  MCCDPA  input  includes  maintenance  of  databases  (HMF,  OSF, 
etc.)  and  DBMS  files.  System  output  to  the  MCCDPA  consists  of  updated  data  elements,  system 
security,  and  DBMS  applications  programs.  The  assumption  is  that  the  MMOA  Database 
Administrator  (DBA)  and  the  MCCDPA  DBA  will  work  closely  together  to  operate  and  maintain 
OADSS.  The  fourth  and  final  system  interface  will  be  with  the  organization  responsible  for 
running  the  OSGM;  currently  Control  Data  Corporation  (CDC).  System  input  from  this  source  will 
be  the  “old”  (from  a  previous  OSGM  run)  OSGM  Dictionary.  Modifications  will  be  made  to  the 
Dictionary  via  interactive  update  procedures  and  the  system  will  output  the  “new”  Dictionary  to 
CDC.  A  close  working  relationship  must  be  maintained  between  MMOA  and  the  other  three 
organizational  entities  for  system  implementation  to  be  successful. 
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Leveled  Set  of  Data  Flow  Diagram  Component? 

A  “leveled  set”  of  DFDs  graphically  represents  the  proposed  system  by  partitioning  it  into 
functionally  primitive  mini-systems  or  processes.  A  complete  set  of  leveled  DFDs  is  composed  of 
the  following: 

1.  Context  Diagram  or  Relative  Context  Diagram-this  is  the  extreme  top-level  graphic 
representation  of  the  system  or  subsystem  under  study  and  appears  as  Figure  2. 

2.  Figure  0— this  is  a  graphic  representation  of  the  next  level  down  from  the  Context  Diagram 
and  reflects  a  high  level  partitioning  of  the  system.  Each  mini-system  or  process  declared  on  the 
figure  is  assigned  a  number  (starting  with  1)  but  this  is  simply  a  reference  point  and  not  reflective 
of  an  ordered  sequence. 

3.  Child  Diagrams— this  is  a  graphic  representation  of  yet  a  lower  level  in  that  partitioning  of 
the  parent  mini-system  from  the  previous  level  is  accomplished.  Each  child  diagram  figure  name 
and  figure  number  will  be  that  of  its  parent  mini-system.  Each  mini-system  declared  on  the  child 
figure  is  assigned  the  number  of  the  figure  number,  a  decimal  point,  and  a  unique  local  number 
(starting  with  1).  Refer  to  Appendix  B  to  review  the  content  of  each  child  diagram. 

To  reiterate,  the  leveled  set  is  comprised  of  a  Context  Diagram  (Level  0),  Figure  0  (Level  1), 
and  Child  Diagrams  (Level  2).  The  system  becomes  more  “decomposed”  at  each  level  in  the 
hierarchy,  thus  providing  an  excellent  summary  of  relationships  among  mini-systems. 

Figure  0 

Figure  0  (Level  1)  is  presented  in  Figure  3  and  illustrates  the  seven  mini-systems  (processes) 
displayed  earlier  on  the  DFD  (Figure  1).  Labels  provided  on  the  input/output  arcs  clearly  describe 
the  nature  of  interaction  between  OADSS  and  the  respective  mini-systems.  The  system  is 
extremely  user-oriented  as  the  mini-systems  are  directed  towards  providing  process-dependent 
feedback  to  user  demands.  By  this  partitioning  into  mini-systems,  the  operational  capabilities  of 
OADSS  are  clearly  and  concisely  defined. 

Child  Diagrams 

Child  diagrams  (Level  2)  for  the  seven  mini-systems  are  presented  in  Figures  B-l  through  B- 
7  of  Appendix  B.  These  figures  partition  the  respective  mini-systems  into  their  component  parts. 
To  better  understand  these  processes,  a  brief  description  of  components  is  provided  below  for  each 
mini-system. 

System  Operations  Subsystem  (Figure  B-l) — this  subsystem  will  be  accessed  only  by  the  DBAs 
at  the  MCCDPA  and  in  MMOA  to  carry  out  the  “housekeeping  chores”  for  the  system.  The  five 
components  of  the  subsystem  are:  (1)  system  security,  (2)  database  maintenance,  (3) 
telecommunications,  (4)  system  backup,  and  (5)  DBMS  maintenance.  The  DBAs  will  be 
responsible  for  all  such  system  maintenance  and  interface  considerations;  all  of  which  should  be 
transparent  to  users. 
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Figure  3.  Level  1:  Figure  0  of  the  leveled  set. 

Report  Generation  Subsystem  (Figure  B-2)— this  subsystem  will  be  used  to  generate  reports 
based  on  user- specified  criteria.  This  includes  formalized  management  reports  as  well  as  informal, 
need-specific  queries.  The  key  factor  is  utilization  of  the  DBMS  Applications  Generator.  This 
processor  will  “build”  (including  criteria  selection  and  output  format)  the  report  request  without 
requiring  the  user  to  have  expertise  in  the  DBMS  programming  language.  The  five  components  of 
the  subsystem  are:  (1)  DBMS  Applications  Generator,  (2)  access  database,  (3)  format  report,  (4) 
designate  action/output  mode,  and  (5)  print  report. 

Statistical  Analysis  Subsystem  (Figure  B-3)-this  subsystem  is  designed  to  perform  statistical 
calculations  required  to  conduct  assignment  procedures.  As  statistics  required  typically  involve 
standard  analyses,  the  statistical  functions  of  the  DBMS  are  satisfactory.  As  with  the  previous 
subsystem,  the  DBMS  Applications  Generator  will  be  used  to  produce  processing  requests.  The 
five  components  of  this  subsystem  are:  (1)  DBMS  Applications  Generator,  (2)  access  database,  (3) 
perform  calculations,  (4)  designate  action/output  mode,  and  (5)  print  results. 

Data  Element  Update  Subsystem  (Figure  B-4)-this  subsystem  provides  an  on-line  facility  for 
users  to  update  OADSS  databases.  As  personnel  information  is  highly  dynamic,  it  is  essential  that 
the  database  is  as  current  and  as  accurate  as  possible.  The  seven  components  of  :h:  „ubsyst*,:ii  are: 
(1)  access  database,  (2)  add  data,  (3)  delete  data,  (4)  update  data  (for  existing  data),  (5)  data 
verification/rules,  (6)  modify  database,  and  (7)  transaction  summary.  The  last  component  provides 
users  with  a  DBMS-generated  summary  of  how  many  attempted  changes  were  accepted  or 
rejected. 


User  Training  Subsystem  (Figure  B-5)— this  subsystem  provides  a  variety  of  Monitor-oriented, 
computer-based  training  sessions  in  a  stand-alone  environment  (microcomputer).  User  interaction 
will  be  stressed  and  additional  training  sessions  “lessons”  will  likely  be  added  after  system 
implementation.  The  five  components  of  the  subsystem  are:  (1)  select  training  session,  (2)  conduct 
training  session,  (3)  access  sample  database,  (4)  access  DBMS,  and  (5)  user  interaction. 

Ad  Hoc  Query  Subsystem  (Figure  B-6)— this  subsystem  provides  users  with  fast,  easy  access 
to  assignment-related  data  elements  in  the  OADSS  database  and  is  the  heart  of  the  proposed 
system.  The  DBMS  Applications  Generator  will  enable  users  to  execute  even  complex  queries 
without  requiring  experience  with  DBMS  language  and  syntax.  This  capability  will  promote 
effective  utilization  of  computer  resources  and  will  substantially  reduce  the  “clerical”  workload  of 
Monitors.  The  five  components  of  the  subsystem  are:  (1)  DBMS  Applications  Generator,  (2) 
access  database,  (3)  format  output,  (4)  designate  action/output  mode,  and  (5)  print  query  results. 

OSGM  Dictionary  Maintenance  Subsystem  (Figure  B-7)— this  subsystem  will  provide  a  means 
for  Monitors  to  interactively  maintain  their  portion  of  the  OSGM  Dictionary.  Such  a  capability  will 
encourage  active  participation  by  Monitors,  reduce  input  errors,  and  reduce  work  demands  on  the 
GoGIVi  Officer.  The  eight  components  of  the  subsystem  are:  (1)  Select  Maintenance  Procedure,  (2) 
access  OSGM  Dictionary,  (3)  add  records,  (4)  delete  records,  (5)  update  records,  (6)  data 
verification/rules,  (7)  modify  OSGM  Dictionary,  and  (8)  print  records. 

Figure  4  provides  a  graphic  summary  of  the  relationship  between  the  seven  subsystems 
discussed  above  and  the  six  system  modules  presented  in  the  FD  (Chatfield  &  Guilett,  1989).  As 
is  readily  apparent,  several  of  the  subsystems  interact  with  virtually  all  of  the  modules  (e.g.. 
Perform  System  Operations  on  all  but  the  AMOS).  In  contrast,  OSGM  Dictionary  Maintenance 
and  User  Training  are  very  modular-specific.  From  a  summary  standpoint,  the  information 
conveyed  in  Figure  4  reflects  the  scope  of  each  of  the  OADSS  subsystems. 

Mini-specification 

A  mini- specification  (mini-spec)  is  a  statement  of  the  logical  requirements  governing  the 
transformation  of  input  data  flows  into  output  data  flows  at  the  functionally  primitive  mini-system, 
or  process  level.  While  drafting  of  mini-specs  is  a  valuable  design  aid,  it  is  not  appropriate  for 
OADSS  because  the  subsystems  are  not  declared  at  the  lowest  level.  That  is,  the  subsystems  are 
often  inextricably  tied  to  the  functionality  of  the  DBMS.  Because  of  this,  it  is  not  feasible  to 
partition  the  proposed  system  to  a  level  where  delineation  of  mini-specs  is  possible.  Subsystems 
will  include  applications  generation,  data  verification,  and  several  other  functions  that  are 
relatively  complex.  And,  as  these  capabilities  are  actually  a  component  of  the  DBMS,  it  is  not 
necessary  to  provide  a  design  for  mini-specs. 

Information  Modeling 

This  section  describes  the  product  of  an  approach  to  modeling  essential  memory  known  as 
entity-relationship  analysis;  the  Entity-relationship  Diagram  (F.RD).  Figure  5  displays  the  ERD, 
providing  a  graphic  summaiy  of  entities  needed  in  essential  memory  as  well  as  illustrating  the 
relationships  among  them.  All  of  the  entities  in  the  ERD  were  previously  discussed  in  the  FD 
(Chatfield  &  Guilett,  1988)  and  DRD  (Chatfield  &  Guilett,  1990).  However,  the  ERD  is  valuable 
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Figure  4.  Summary  of  relationship  between  officer  assignment  decision  support  system 

(OADSS)  subsystems  and  modules. 


Figure  5.  Entity-relationship  diagram  (ERD). 


for  identifying  the  capabilities  of  the  New  Logical  Model  (see  funtional  description  (FD))  to  meet 
user  informational  needs.  Thus,  issues  concerning  data  entity  relationships  can  be  raised  by 
reviewing  the  ERD.  Information  conveyed  in  the  Data  Dictionary  (Appendix  B  of  the  requirements 
document  (RD))  is  of  course  the  starting  point  for  derivation  of  the  ERD.  The  Data  Dictionary 
summarizes  all  data  elements  stored  by  the  Logical  Model  to  accomplish  system  capabilities. 
Normally,  mini-specifications  are  used  to  provide  inter-object  (i.e.,  entity)  relationships.  However, 
this  was  not  realistic  for  the  proposed  system  due  to  DBMS  interfaces.  Therefore,  the  ERD  is  based 
principally  upon  the  Data  Model  Diagram  and  the  New  Physical  Model.  The  entity-relationship 
model  was  derived  by  partitioning  elements  in  the  Data  Dictionary  into  homogeneous  entities. 
Then,  each  entity  was  given  a  name  that  described  the  criteria  for  grouping  the  elements  together. 
For  example,  the  Security  Entity  contains  only  three  data  elements  (level  of  security  clearance,  date 
of  security  clearance,  and  type  of  security  investigation),  all  of  which  provide  information  about 
an  officer’s  security  clearance.  Once  this  has  been  accomplished,  the  ERD  can  be  established  as  a 
means  of  summarizing  relationships  among  entities.  The  ERD  has  two  basic  components: 

1 .  Entity- an  object,  or  store  of  data.  Each  entity  is  represented  on  the  ERD  as  a  box. 

2.  Relationship— a  set  of  connections  that  relate  two  or  more  entities.  Each  relationship  is 
represented  on  the  ERD  as  a  diamond.  In  the  instance  where  a  relationship  also  represents  an  entity, 
it  is  represented  as  a  box  with  a  diamond  superimposed. 

Referring  to  Figure  5,  the  central  relationship  is  between  the  Officer  Monitor  and  Assignment 
Processing  entities.  This  relationship  is  labeled  “Assignment  Decision-making”  and  incorporates 
the  plethora  of  data  elements  that  influence  a  Monitor’s  assignment  decisions.  Because  of  the 
complexity  of  the  ERD,  the  information  below  is  provided  to  summarize  the  relationships  among 
entities  and  how  each  relationship  is  tied  to  “Assignment  Decision-making.”  The  linking  of 
relationships  to  this  focal  relationship  for  the  system  is  referred  to  as  the  “path.” 


Relationship/Path 

Marine  Officer 

via  Officer-Specific  Factors 

Supplemental  Factors 
via  Officer-Specific  Factors 


Historical  Factors 

via  Officer-Specific  Factors 


OSGM 

via  Billet-Specific  Factors 

Current  Assignment 
via  Billet-Specific  Factors 

Officer  Monitor 
Assignment  Processing 


Entities 

Security 
Dependents 
Officer  MOS 

Assignment  Preference 
Special  Education 
Program  (SEP) 

Aviation  Career  Incentive 
Pay  (ACIP) 

Fitness  Report  of  Officers 
(FITREP)  History 
Former  Assignment 
Training/Education 

Mobilization 
MOS  Type 

Table  of  Manpower 
Requirements  (TMR) 

N/A 

Advance  Assignment 
Future  Assignment 
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The  names  of  the  relationships  are  self-explanatory  for  identifying  why  particular  entities  were 
grouped  together.  However,  it  should  be  noted  that  the  following  entities  (data  stores)  were  also 
used  to  denote  relationships:  (1)  OSGM,  (2)  assignment  processing,  and  (3)  marine  officer.  For 
more  specific  information  about  the  content  of  data  stores,  refer  to  the  FD  and  RD  documents. 

Organizational  Context 


OADSS  will  operate  within  MMOA  located  at  HQMC.  The  Director,  Personnel  Management 
Division  (MM),  under  the  direction  of  the  Deputy  Chief  of  Staff  for  Manpower,  is  responsible  for 
administration  and  retention  of  officer  and  enlisted  Marine  Corps  personnel;  and  distribution, 
appointment,  promotion,  retirement,  and  discharge  of  commissioned  officers,  warrant  officers,  and 
enlisted  personnel.  Within  this  purview,  MMOA  is  specifically  responsible  for  administering  the 
assignment  and  classification  of  all  Marine  Corps  officers  (colonel  and  below).  Figure  6  illustrates 
the  organizational  structure  of  MMOA.  MMOA  is  comprised  of  five  sections,  two  of  which 
essentially  provide  support  services  for  officer  Monitors.  The  sections  within  MMOA  and  their 
primary  responsibilities  are  outlined  below. 


Section 


Responsibility 


MMOA-1 

MMOA-2 

MMOA-3 

MMOA-4 

Administrative 


Ground  Officer  Assignment 
Aviation  and  Aviation/Ground  Officer  Assignment 
Plans,  Policy,  Systems,  and  Special  Programs 
Aviation  and  Ground  Colonel  Assignment 
Administrative  Service  for  Branch 


Figure  6.  Organization  of  the  officer  assignment  branch  (MMOA). 
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Sections  MMOA-1,  MMOA-2,  and  MMOA-4  are  responsible  for  the  actual  assignment  of 
officers  within  their  respective  populations  (indicated  by  Monitor  Activity  Code  (MAC)).  MMOA- 
3  coordinates  administration  of  the  SEP,  lateral  MOS  moves,  and  retention  and  release  matters. 
MMOA-3  (Systems),  formerly  MMOA-5  (Operations  Analysis  and  Systems  Support),  coordinates 
running  the  OSGM  and  provides  a  wide  range  of  analysis  and  programming  support  for  the  other 
MMOA  sections.  While  a  full  discussion  of  all  MMOA  responsibilities  is  well  beyond  the  scope 
of  this  document,  the  primary  assignment-related  functions  are  presented  below: 

1.  Effects  and  monitors  assignment  of  all  officers  (LtCol  and  below). 

2.  Issues  travel  orders  for  officers  in  accordance  with  approved  policies,  laws,  and  fiscal/ 
travel  regulations. 

3.  Administers  delay  in  route  leave  between  duty  stations. 

4.  Classifies/reclassifies  officers. 

5.  Enters  personnel  data  into  appropriate  data  files  (e.g.,  OSF,  MMS). 

6.  Assigns  officers  to  professional  education  schools  while  following  established  assignment 
policies. 

7.  Assigns  officers  to  military  schools  in  conjunction  with  the  Deputy  Chief  of  Staff  for 
Training  and  occupational  field  sponsors. 

In  carrying  out  officer  assignment  responsibilities,  MMOA  is  supported  by  several 
organizational  entities  which  maintain  databases  accessed  by  officer  Monitors.  For  example,  the 
Fitness  Report  Section  (MMOS-2)  of  the  Operations  and  Support  Branch  (MMOS)  is  responsible 
for  processing  and  distributing  FITREPS.  Master  Brief  Sheets  are  also  a  product  of  MMOS.  On  a 
larger  scale,  JUMPS/MMS  is  maintained  by  the  MCCDPA,  Kansas  City,  and  the  HMF  by  the 
MCCDPA,  Quantico.  Overall,  Automated  Data  Processing  (ADP)  support  of  MMOA  is  handled 
by  the  MCCDPA,  Quantico.  This  support  includes  centralized  file  maintenance,  access  to  the 
AMDAHL  mainframe  computer,  and  coordinating  data  communications  between  HQMC  and  the 
MCCDPA.  As  discussed  earlier,  successful  implementation  of  OADSS  is  contingent  upon  close 
cooperation  between  MMOA  and  the  MCCDPA,  Quantico;  particularly  at  the  DBA  level. 

Automated  Data  Processing  Equipment  (ADDPE)  Environment 

The  recommended  operational  environment  for  the  proposed  system  is  the  AMDAHL 
mainframe  environment  at  the  MCCDPA,  Quantico.  As  discussed  in  the  Feasibility  Study 
(Chatfield  &  Gullett,  1989),  the  ideal  ADPE  for  OADSS  would  be  a  MMOA-dedicated 
minicomputer  to  ensure  rapid  system  response.  However,  MMOA  manning  constraints  and  an 
inability  to  procure  such  equipment  within  the  OADSS  project  time  frame  precludes  further 
pursuing  this  alternative.  Although  it  was  not  initially  the  recommended  alternative,  the  mainframe 
environment  should  be  suitable  for  system  implementation  as  recent  major  upgrades  have 
significantly  reduced  system  response  time  decrement.  This  section  presents  the  ADP  environment 
in  which  OADSS  will  operate  as  well  as  an  overview  for  transitioning  from  microcomputer-based 
prototypes  to  a  fully  operational  mainframe- based  system.  Both  equipment  requirements  within 
the  MCCDPA,  Quantico,  and  MMOA  will  be  addressed. 
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Marine  Corps  Central  Design  and  Programming  Activity  (MCCDPA),  Quantico 

The  operating  environment  at  the  MCCDPA  is  configured  to  provide  large-scale  data 
processing  support  to  a  number  of  Marine  Corps  organizations.  The  MCCDPA,  Quantico  provides 
services  to:  HQMC;  Marine  Corps  staff  agencies;  the  Marine  Corps  Development  and  Education 
Command  (MCDEC);  the  Computer  Sciences  School;  and  several  other  Marine  Corps  facilities 
located  in  the  Washington,  DC  area.  The  following  subsections  discuss  various  components  of  the 
ADP  environment. 

1.  Processors.  The  MCCDPA  operates  two  AMDAHL  470/V8  mainframe  computers  in  a 
coupled  configuration  to  support  both  batch  and  on-line  processing.  The  AMDAHL  470  machine 
is  compatible  with  International  Business  Machines  (IBM)  equipment  and  has  an  architecture 
similar  to  that  of  the  IBM  370.  Each  processor  contains  16  megabyte  (MB)  of  real  memory. 

2.  Storage.  A  variety  of  storage  media  and  devices  are  currently  available  within  the 
MCCDPA.  Strings  of  IBM  3380  disk  storage  devices  (single-density)  provide  direct  access 
storage.  In  addition,  magnetic  tape  storage  is  available  for  off-line  storage  and  backup  of  the  direct 
access  devices.  Storage  Technology  Corporation  (STC)  3650  and  3670  tape  drives  provide  both  7- 
track  and  9-track  tape  storage  capabilities. 

3.  Input/Output  Devices.  A  number  of  input/output  devices  are  available  to  users.  This  list 
of  devices  includes  card  readers,  card  punches,  line/laser  printers,  and  microfiche  production 
equipment. 

4.  Communications.  Communications  with  the  AMDAHL  mainframe  environment  is 
controlled  via  COMTEN  communications  processors.  Specifically,  a  COMTEN  3690  is  attached 
to  each  470/V8  for  communications  purposes.  Communication  between  HQMC  and  the  MCCDPA 
is  provided  by  three  dedicated  communications  lines,  each  with  a  peak  transmission  rate  of  50 
kilobyte  (KB).  These  transmission  lines  are  part  of  the  Marine  Corps  Data  NetworK  (MCDN) 
which  provides  communications  with  other  Marine  Corps  sites.  The  transmission  rate  of  the 
MCDN  ranges  from  1200  bits  to  19.2  KB  per  second. 

Officer  Assignment  Branch  (MMOA) 

As  discussed  earlier,  OADSS  modules  (subsystems)  will  be  developed  on  a  prototype  basis  in 
a  microcomputer  environment.  Two  complete  microcomputer  systems  will  be  added  to  MMOA 
and  will  satisfy,  at  a  minimum,  the  following  requirements: 

1.  IBM  compatibility 

2.  640  KB  RAM 

3.  20  MB  hard  disk 

4.  High  resolution  monochrome  monitor 

5.  One  360  MB  floppy  drive 

6.  Graphics  capability 

7.  Dot  matrix  printer 
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In  addition  to  the  above  requirements,  one  of  the  systems  will  include  a  1200  baud  modem 
while  the  other  will  include  a  terminal  emulation  board  (e.g.,  IRMA  Board).  This  equipment  is 
needed  to  transfer  data  within  HQMC  and  between  HQMC  and  the  MCCDPA,  Quantico.  In 
addition,  the  modem-equipped  system  will  include  approximately  60  MB  of  auxiliary  storage  to 
handle  large  databases.  Figures  7  through  12  illustrate  the  proposed  hardware/software 
configuration  for  each  OADSS  module.  A  large  box  is  used  to  denote  hardware  while  a  smaller, 
attached  box  indicates  the  software  to  be  used.  Communications  between  ADPE  environments  are 
illustrated  with  solid  lines;  arrows  indicate  the  direction  of  data  flows.  Both  the  prototype  and 
transition  configuration  are  presented  for  each  module  to  comprehensively  detail  ADPE 
considerations.  However,  as  the  AMOS  will  operate  in  strictly  a  microcomputer  environment  it  has 
no  transition  period. 

Software  Environment 

Mainframe- based  software  required  to  support  the  proposed  system  is  all  currently  in  place. 
The  Multiple  Virtual  Storage  (MVS)  operating  system  will  continue  to  control  system  operations 
and  activities.  The  Advanced  Communications  Facility/Virtual  Telecommunications  Access 
Method  (ACF/VTAM)  package  provides  control  of  all  on-line  processing.  OADSS  databases  and 
ad  hoc  query  functions  will  largely  migrate  from  the  Adaptable  Database  System  (ADABAS) 
NATURAL  DBMS  to  the  FOCUS  DBMS.  This  transition  is  necessitated  by  the  fact  that  FOCUS 
is  much  more  user  friendly  thanks  principally  to  its  TABLETALK  implementation  of  Applications 
Generator  technology.  However,  FOCUS  is  capable  of  reading  ADABAS  files  and  thus  this  may 
eliminate  the  need  to  actually  transfer  large  databases  to  FOCUS  format.  Microcomputer  software 
will  include  the  PC/FOCUS  DBMS,  the  R:base  5000  DBMS,  AutoMentor,  and  Cross-talk  XVI. 
PC/FOCUS  will  be  used  to  develop  most  applications  programs  in  OADSS;  all  of  which  will  be 
completely  transportable  to  mainframe  FOCUS.  R:base  5000  is  currently  used  extensively  within 
MMOA-3  and  some  consideration  is  being  given  to  using  it  rather  than  PC/FOCUS  for  the  OSGM 
Interactive  Maintenance  module.  AutoMentor  (or  similar  tutoring  software)  will  be  used  to 
develop  lessons  for  the  AMOS  module.  Finally,  Crosstalk  XVI  will  be  used  for  modem 
communications. 

New  Performance  Characteristics 

Implementation  of  the  proposed  system  will  allow  Monitors  to  provide  significantly  better 
“customer  service”  to  constituents.  That  is,  improved  system  response  time  and  user-friendly  ad 
hoc  query  capabilities  will  enable  Monitors  to  provide  constituents  with  very  rapid,  timely 
feedback  to  assignment-related  questions  and  concerns.  In  addition,  OADSS  will  dramatically 
reduce  the  “clerical”  workload  of  Monitors  by  replacing  present  manual,  labor-intensive 
processing  with  automated  procedures.  However,  due  to  the  nature  of  the  assignment  process,  it  is 
impossible  to  state  precisely  how  long  a  Monitor  will  spend  using  the  system  to  make  an 
assignment.  In  reality,  the  review  of  data  elements,  interaction  with  constituents,  and  other  related 
activities  are  often  spread  over  several  weeks  and  are  non-sequential.  A  conservative  estimate  is 
that  implementation  of  OADSS  will  reduce  the  “throughput”  time  for  each  assignment  by  50 
percent. 

Monitors  will  access  the  system  primarily  to  identify  constituents  meeting  selected  criteria 
(e.g.,  MOS,  paygrade,  educational  background).  Response  time  to  such  queries  will  depend  on 
several  factors;  among  them  are  response  time  of  the  AMDAHL  (typically  moderated  by  the 
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Prototype 


Transition 


Figure  7.  Special  education  program  (SEP)  administration  module. 


Prototype 


Transition 


Figure  8.  Annual  slate  letters/monitor  notes  module. 
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Transition 


Figure  9.  Officer  promotion  database  module. 


Prototype 


Transition 


Figure  10.  Improved  database  access  module. 
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Not  applicable 


Figure  11.  Automated  monitor  orientation  subsystem  (AMOS)  module. 


Prototype 


Figure  12.  Officer  staffing  goal  model  (OSGM)  interactive  maintenance  module. 


22 


number  of  concurrent  on-line  users),  type  of  query  (large  sorts  are  very  demaning  on  the  central 
processing  unit  (CPU)),  location  and  layout  of  database  accessed,  user’s  priority  level,  and 
processing  efficiency  of  the  query.  Therefore,  while  an  accurate  estimate  of  response  time  cannot 
be  established,  it  is  projected  that  queries  of  medium  complexity  (selection  on  four  or  five  criteria) 
will  be  completed  in  1-3  minutes.  Updates  of  data  elements  will  be  processed  much  faster, 
requiring  only  5-10  seconds  to  complete.  System  response  time  decrement  under  periods  of  heavy 
usage  is  anticipated.  The  volume  of  throughput  will  vary  among  Monitors  as  the  number  of 
constituents  for  each  ranges  from  approximately  240-2000.  Obviously,  those  Monitors  with  larger 
populations  will  utilize  the  system  to  a  greater  extent  than  their  peers.  It  is  important  to  reiterate 
that  system  functions  are  not  sequential  and  the  modular  approach  allows  access  to  a  subsystem  at 
any  time  via  the  OADSS  main  menu. 

Information  Requirements 

This  paragraph  summarizes  information  requirements  of  the  New  Physical  Model  in  terms  of 
transaction  inputs  and  outputs.  These  information  requirements,  which  can  be  divided  into  five 
specific  areas,  are  discussed  below. 

1 .  Add,  Delete,  Edit  Data.  Maintenance  of  data  elements  is  critical  to  keeping  information  up- 
to-date  and  accurate.  Hence,  a  primary  “input”  to  the  system  will  be  addition,  deletion,  and  editing 
of  resident  data  elements.  This  will  be  accomplished  using  menu-driven  procedures  and  easy-to- 
use  “screen  forms.” 

2.  Database  Query  and  Retrieval.  The  primary  requirement  for  OADSS  is  that  it  provide 
Monitors  with  powerful,  yet  easy-to-use  ad  hoc  query  and  data  retrieval  capabilities.  Ad  hoc  query 
will  allow  a  Monitor  to  specify  criteria  for  identifying  candidate  officers  to  fill  a  billet.  For 
example,  the  Monitor  may  wish  to  identify  all  individuals  that  have  a  MOS  of  9612,  are  not 
married,  and  have  a  preference  for  assignment  in  the  Fleet  Marine  Force  (FMF)  on  the  west  coast. 
By  using  OADSS  to  review  a  wide  scope  of  pertinent  information.  Monitors  will  free  themselves 
from  the  slow,  laborious,  manual  methods  now  used.  The  DBMS  Applications  Generator  will  be 
employed  as  a  front-end  processor  so  that  queries  and  retrievals  are  automatically  formatted  to  be 
phrased  in  the  proper  language  and  syntax.  In  addition  to  ad  hoc  query,  records  for  individual 
officers  will  be  able  to  be  retrieved. 

3  Print  Reports.  The  primary  “output”  of  the  system  will  be  feedback  to  ad  hoc  query 
requests.  Typically,  these  “reports”  will  be  viewed  on  the  Video  Display  Terminal  (VDT)  screen. 
Then,  if  the  user  requests,  the  report  can  be  printed  in  a  specified  format.  Once  again,  the  DBMS 
Applications  Generator  will  be  used  to  format  the  request  for  report  output. 

4.  Statistical  Analysis.  The  results  from  statistical  analyses  will  also  be  an  important  system 
output.  While  statistical  analysis  will  typically  be  limited  to  simple  descriptive  statistics  (frequency 
counts,  averages,  etc.),  access  to  more  advanced  analyses  such  as  multiple  regression  will  also  be 
available.  Again,  the  DBMS  Applications  Generator  will  be  utilized  to  provide  a  user-friendly 
interface  between  Monitors  and  DBMS  language  and  syntax. 

5.  Menu  Selection.  The  final  input  to  the  system  will  be  users’  selections  from  menus 
provided.  The  OADSS  main  menu  will  be  used  to  access  system  modules  while  module  sub-menus 
will  be  used  to  carry  out  actual  applications.  The  proposed  system  will  be  menu-driven  to  the 
greatest  extent  possible  to  facilitate  ease-of-use. 
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RECOMMENDATIONS 


1.  A  Detailed  Design  Specification  (DDS)  should  be  completed  by  the  system  designer  (i.e., 
NPRDC)  as  the  next  step  in  the  “definition  and  design”  phase  of  system  development. 

2.  In  concert  with  the  modular  approach  to  system  development,  “rapid  prototyping”  should 
be  used  as  a  means  of  minimizing  system  development  time  and  ensuring  the  active  participation 
of  end  users. 
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TERMS  AND  ABBREVIATIONS 


ACF/VTAM 

ACEP 

ADABAS 

ADP 

ADPE 

ACS 

AIS 

CDC 

CMC 

DBA 

DBMS 

DFASC 

DFD 

DoD 

DRD 

DSS 

ERD 

FD 

FITREP 

FMF 

GDS 

HMF 

HQMC 

HQO 

HQORGMAN 

JUMPS/MMS 

KB 

LCM 

LCM-AIS 


Advanced  Communications  Facility/Virtual  Telecommunications 

Access  Method 

Aviation  Career  Incentive  Pay 

Adaptable  Data  Base  System 

Automated  Data  Processing 

Automated  Data  Processing  Equipment 

Automated  Data  System 

Automated  Information  Systems 

Control  Data  Corporation 
Commandant  of  the  Marine  Corps 

Data  Base  Administrator 

Data  Base  Management  System 

Deployable  Force  Automated  Service  Center 

Data  Flow  Diagram 

Department  of  Defense 

Data  Requirements  Document 

Decision  Support  System 

Entity-Relationship  Diagram 

Functional  Description 
Fitness  Report  of  Officers 
Fleet  Marine  Force 

General  Design  Specification 

Headquarters  Master  File 
Headquarters,  U.S.  Marine  Corps 
Headquarters,  U.S.  Marine  Corps  Order 
Headquarters,  U.S.  Marine  Corps  Organization  Manual 

Joint  Uniform  Military  Pay  System/Manpower  Management  System 

Kilobyte 

Life  Cycle  Management 

Life  Cycle  Management  of  Automated  Information  Systems 
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MB 

MCCDPA 

MCDEC 

MCDN 

MCO 

MMOA 

MMOS 

MMPR 

MMS 

MOS 

MPI 

MVS 

OADSS 

OSF 

OSGM 

PCS 

PREPAS 

RASC 

REMMPS 

STC 

TMR 

USMC 

VDT 


Megabyte 

Marine  Corps  Central  Design  and  Programming  Activity 

Marine  Corps  Development  and  Education  Command 

Marine  Corps  Data  Network 

Marine  Corps  Order 

Code  for  Officer  Assignment  Branch 

Code  for  Operations  and  Support  Branch 

Code  for  Promotions  Branch 

Manpower  Management  System 

Military  Occupational  Specially 

Code  for  Manpower  Management  Information  Systems  Branch 
Multiple  Virtual  Storage 

Officer  Assignment  Decision  Support  System 

Officer  Slate  File 

Officer  Staffing  Goal  Model 

Permanent  Change  of  Station 
Precise  Personnel  Assignment  System 

Regional  Automated  Service  Center 
Reserve  Military  Manpower  Pay  System 

Storage  Technology  Corporation 

Table  of  Manpower  Requirements 

United  States  Marine  Corps 

Video  Display  Terminal 


A-2 


APPENDIX  B 
CHILD  DIAGRAMS 
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Symbol 


Data  Flow 


A 

B 

C 

D 

E 

F 

G 

H 

I 


File  Maintenance 
Data  Communications 
Access/Analyze  Data 
Sub-system  Input/Output 
DBA  Input 
User  Request/Input 
User  Feedback 
Training  Input 
Sub-system  Operations 


Figure  B-l.  Legend  for  interpreting  child  diagram  data  flows. 
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Figure  B-3.  Level  2:  Statistical  analysis  subsystem. 


Figure  B-7.  Level  2:  OSGM  dictionary  maintenance  subsystem. 
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